In enterprise systems including legacy software, such as aging software, there is a reluctance to change the legacy software due to a risk that the software may operate unpredictably or inefficiently. The extent of this problem can increase with the age of legacy software and the level of documentation, support, and developer experience recedes. However, it is often necessary for the operation of such legacy software to be adapted, supplemented, or otherwise affected in order to provide facilities and services required of modern data processing systems. It would be most advantageous if such changes to legacy software did not necessitate the rewriting or replacement of the software where the software is otherwise considered to be reliable and effective.
In the prior art, aspect oriented programming (AOP) techniques are employed to weave aspects of code into predefined join-points within a software application. The use of aspect oriented programming techniques is not effective in addressing the aforementioned problem for at least two reasons. Firstly, applications for which aspect oriented programming approaches are applied must be developed with aspect oriented programming in mind and must therefore be architected accordingly so as to be parsed by an aspect weaver. Legacy software may exist in only its compiled form, such as a machine code executable form, and is not necessarily developed in an aspect oriented programming language (such as have been available only relatively recently, and as are discussed in U.S. Pat. No. 6,467,086 Assigned to Xerox Corporation). Secondly, in order to strictly define points in a legacy application for the purpose of aspect weaving, it would be necessary to be able to uniquely identify such points by way of satisfying an aspect rule. In any event, to employ technology such as aspect oriented programming for legacy systems it will be necessary to provide aspect support for legacy programming languages (including Cobol, PL/1, Fortran, and assembly languages) and a recompilation of the legacy system will be required to weave newly developed aspect code for inclusion into resulting executable binaries. Such a development would involve substantial effort possibly correlating to the effort required to replace a legacy system.
Another technology available in the prior art involves executing software routines in a special mode known as “debug mode”. Debug mode provides for the setting of breakpoints and effecting changes to an application state interactively by a software developer during software development. Such debug technologies require that applications include debug code (such as data definitions and references to source code) that result in a larger runtime executable and poor runtime performance. Consequently, debug code is normally not included in production runtime binaries since these require high performance and are not intended to be run with an interactive debugger. Furthermore, a decision to include debug code into a software routine is made at build-time, and legacy software available only in its compiled runtime production form cannot necessarily be rebuilt (i.e., recompiled, linked and packaged). Yet further, the function of such a debug mode is specifically directed to providing problem determination and resolution facilities at development time, and involves interactive use of debugger software by a software developer. It is unlikely to be acceptable to involve a software developer interactively in supplementing a legacy software routine at production runtime.
It would therefore be advantageous to provide for the augmentation of compiled legacy software without rewriting or replacement of the software where the software is otherwise considered to be reliable and effective.